Remote DTC Connectivity

Remote DTC Connectivity

DTCs utilize a proprietary protocol called Avesta Flow Control Protocol. AFCP is an Ethernet protocol and is not routable. As with all Ethernet protocols, AFCP traffic can be bridged. Network administrators tend to discourage the use of bridging due to the potential for sending too much unwanted traffic across the remote networks.

In my opinion the best alternative is to eliminate DTCs altogether. There are plenty of alternatives to DTC connections including:

• Replace remote dumb terminals with PCs using network connections
• Connect remote dumb terminals to Telnet line drivers instead of RS-232 connections
• Connect remote dumb terminals to Telnet servers instead of DTCs
• Convert serial printers to networked based printers
• Implement VPN or RAS in place of host-based modem pools.
• Web/network enable applications. Replace terminal access with a browser or Visual Basic application.

Reducing the dependence upon DTCs leads to eliminating the Routable AFCP issue completely. But, if you must utilize DTCs across a WAN here are two ways to route DTC traffic.

Method 1 – Routable AFCP (RAFCP)

RAFCP is the official HP supported method for communicating with remote DTCs. RAFCP uses a front-end DTC on the HP3000 side of the WAN to encapsulate AFCP packets within IP packets. The IP packets then are routed to the remote network. Only specific DTC’s have the ability to act as the front-end DTC. The front-end DTC manages no serial connections itself, its only function is to encapsulate the other DTC traffic.This means that you must have an extra DTC to do the encapsulation. Furthermore, not all DTC’s are supported on the remote side.

RAFCP also requires an OpenView DTC Manager workstation on the remote end of the connection to configure and manage the DTCs. One is required for each and every remote location. The OpenView DTC Manager workstation need not be a high powered PC but each does require the OVDTCMGR software license.

Considering the requirements for an extra DTC on the system side, OpenView DTC Manager workstations, and the fact that the all DTCs are not supported, most sites opt not to implement RAFCP. In fact there are a very limited number of sites using this option.

Method 2 – Data-Link Switching

A better method is to employ Data Link Switching (DLSw), a feature of most modern Cisco routers. Data-Link Switching provides a means of transporting various “non routable” protocols over an IP network and thus can server as an alternative to bridging. According to Cisco, DLSw is documented as a means of transporting SNA and NetBIOS traffic over a remote IP network. We have seen it successfully implemented to route AFCP traffic. I will leave the details up to the router experts, but this is an option that some sites may want to explore. The information in this method is not meant to exclude other brands of routers as they may have a similar capability to CISCO’s DLSw, it is just that we are aware of sites using the CISCO DLS method.

You can read more concerning DLSw on Cisco’s web site on the following page, or go to Cisco’s home page and search on DLSw.

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/DLSw.html